前幾天講到〈產品從無到有〉、〈從驗證完成到開始的準備〉，今天晚點會在《軟體開發隨筆談》系列文講〈為軟體訂定狀態階段〉，都是在講產品的生命週期的一部份。除此之外，雖然還有一部分還沒講到，昨天卻先暫停寫相關題材，改講〈授人以魚，不如授人以漁〉，就是先切回來本專欄的名稱「為團隊與組織導入敏捷的經驗分享」。

從鐵人賽第一天到今天，所有題目幾乎都是我在過去一年陸續導入團隊的一些活動和政策，導入的方式差不多都是透過〈導入敏捷的過程也要敏捷〉裡面所提到的方式，每個開發週期進行一小個改變，然後會利用週期中間的某天，將自己所學的內容，透過主題分享的方式去分享給團隊，成為他們日後制定政策的想法來源。若在分享後，直接照自己所講的去落實，最後就會變成授人以魚，這樣可能會導致導入的政策不符合團隊文化或現況，又或是團隊學到的是死方法、形式，而領悟不到其中敏捷精神。所以要由團隊一起訂定才是好的做法。

而這些逐漸被落實的政策，也透過一天約千字的篇幅去講述這些被導入的內容，而產品生命週期當然也是其一。但是這個部分會比較特別，前面的部分幾乎都只發生在團隊內部，但關於產品生命週期會是整個組織的事情，所以特別強調應該要由組織一起訂定，畢竟研發團隊負責的開發和維護只是產品生命週期的一個部分而已，一個產品的經營，卻是由整個組織一起努力的。任何一個人都很難對產品有全面暸解，所以只有一個人去定義產品的生命週期，是個致命的錯誤。

而我們又為什麼要去定義產品的生命週期呢？組織內部會彼此互相詢問的問題，有很多是和產品的狀態有關，比如說「某某 Bug 到底修了沒？修了？！但我操作還是有問題呀？蛤，還沒部署，那是什麼意思？」、「現在到底有哪些新功能是可以用的？不是說開發很久了？」、「某某產品現在還有在賣嗎？」等等。對於產品目前的狀況，宛如一個迷霧籠罩在組織內部，需要花很多溝通成本去釐清，甚至花了溝通成本得到的答案還是過時的。

我們需要有一個方法能清楚明暸的將產品的狀態對整個組織輻射，而減少互相問來問去的溝通成本，這時候看板作為一個資訊視覺化工具顯然是一個不錯的選擇。找一個下午，組織的所有人員，或是各部門的重要代表（端看組織規模）聚在一起，一起訂定產品的生命週期流程的看板，去釐清每個部門對於與自己叫相關的產品階段的定義，暸解現在產品線的現況，最後將這個看板建立在組織所有人都看得到的地方，比如說某個走廊的牆上，讓上面的資訊得以對所有人輻射。

就像前幾天所描述的，產品的生命週期可能包括，產品從無到有、從第一次上線到後續維護、從最後一次更新到退役的一個過程，這些舉例可能還無法包含整個生命週期，中間還有許多迷霧又去補完。可以將產品的狀態分為幾個大區塊，像是驗證、研發與維護、停止維護，而大區塊又分為好幾個狀態，像是驗證裡面可能有待驗證的想法、訪談中、開發 MVP 中、驗證完等等；研發與維護可能就有待研發、研發中、待檢視、已合併、已部署到 staging、已部署到 production 等；停止維護可能還包括還在賣的、沒在賣了但還有提供客服支援、不提供客服支援、產品停止服務等。

根據每個組織對於產品經營的方式不同、這些階段都不一樣，沒有一個不用更改的通用樣板。所以才需要各部門坐在一起，共同訂定，最後將產品的狀態視覺化。視覺化的方式可以在研究過看板後，針對組織對於產品組合的方向去設計。假設永遠只有經營單個產品，那就每個階段下面都是功能或 bug 的便利貼，如果是多個產品，看是要多個看板還是一個看板但是多個河道，一個河道代表一項產品，到底怎樣呈現比較好，都可以透過討論去激發各種想法。

最後，一個這樣的將產品生命流程視覺化的看板，正如以往所提及的，不會是永恆不變的。除了每天去更新上面的資訊外，定期審視各階段的訂定也是必要的，唯有持續改善，才能適應不斷的變化。